To tolerate the malware and vulnerabilities in large and complex commodity operating systems (OSes), modern secure architectures isolate secure applications (SecApps) from OSes, thereby enabling their safe co-existence. However, safe co-existence does not guarantee the viability and usefulness of the SecApps.
Two fundamental causes of this problem are: (1) To be trustworthy, SecApps must be formally verified, hence small and simple. Thus, they cannot include a variety of basic services available only in large and untrustworthy commodity systems, such as persistent storage, file systems, networking services, and isolated device I/O; and (2) among these services, providing on-demand isolated I/O channels to secure applications is particularly important and challenging, to improve the secure applications' usefulness and viability. Examples include providing secure user interfaces for human-application communication (e.g., keyboard input, screen output), or enabling secure control of remote devices and critical infrastructure (e.g., surveillance cameras, unmanned drones, network-connected electricity generators).
Modern architectures can isolate security-sensitive application code from the untrusted code of commodity platforms, enabling their safe co-existence. This is necessary because large untrustworthy software components will certainly continue to exist in future commodity platforms. Competitive markets with low cost of entry, little regulation, and no liability will always produce innovative, attractively priced, large software systems comprising diverse-origin components with uncertain security properties. Thus, the best one can hope for is that some trustworthy software components can be protected from attacks launched by adversely-controlled giants. To be trustworthy, software components must be verified, and to be verified they must be comparatively small, simple, and limited in function. In contrast to the giants, these software components are wimps.
Unfortunately, isolating these security-sensitive SecApps from untrusted giants does not guarantee the ability of the SecApps to survive on commodity platforms. To avoid re-creating giants inside their isolated execution environments (IEEs), SecApps often give up a variety of basic services for application development, which greatly undermines their usefulness and viability. For example, SecApps typically lack persistent memory, file system and network services, flexible trusted paths to users, and I/O services needed for many applications; e.g., in industrial control, finance, health care, and defense.
Past multi-year efforts to restructure giants (e.g., commercial OSes) to provide trustworthy services for applications led to successful research but failed to deliver trustworthy OSes that met product compatibility and timeliness demands of competitive markets. The alternative of including basic services in the trusted computing bases (TCBs) that guarantee safe giant-wimp co-existence has been equally unattractive. TCBs include, for example, security kernels, micro-kernels, and exokernels, virtual machine monitors, micro-hypervisors, and separation/isolation kernels. TCBs would lose assurance because they would become bloated, unstable, and unverifiable; i.e., they would use large and complex code bases of diverse, uncertain origin (e.g., device drivers) needed for different applications, and require frequent updates because of function additions, upgrades, and patches.
Thus, the only remaining option is to place basic application services in the giants. To survive, SecApps would have to rely on giant-provided services but only after efficiently verifying their results. In turn, SecApps could make their own isolated services available to giants for protection against persistent threats. Continuing with the wimp-giant metaphor, trustworthy SecApps must engage in a carefully choreographed dance (i.e., secure composition) with untrustworthy giants.
Among the basic services needed by SecApps are on-demand isolated I/O channels to peripheral devices, especially character devices (other types of devices, networking and storage devices, can be simply isolated by data encryption). Past attempts to provide such services with high assurance on commodity systems, however, have been unsuccessful. Some provide isolated I/O channels within system TCBs but only for a few selected devices. Even limited support for few devices invariably increases the size and complexity of trusted code and undermines assurance. For example, including just the Linux USB bus subsystem in a micro-hypervisor would more than double its code-base size and increase its complexity significantly; e.g., it would introduce concurrency in serial micro-hypervisor code since it would require I/O interrupt handling. Other attempts statically allocate selected peripheral devices to isolated system partitions at the cost of losing on-demand (e.g., plug-and-play) capabilities of commodity systems. In contrast, other systems provide on-demand I/O capabilities by virtualizing devices or passing them through to isolated guest OSes, but sacrifice I/O channel isolation from the untrusted OSes. Further attempts to isolate I/O channels rely on special hardware devices equipped with data encryption capabilities to establish cryptographic channels to applications. This approach excludes commodity devices, which lack encryption capabilities, and adds TCB complexity by requiring secure key management for the special devices.